To develop systems using the HiPerCopS IDE, users must first understand the building blocks and tools available to them. The IDE provides all of the necessary resources for implementing a design from start to finish. Each step of the process serves a specific purpose, and the steps in the workflow are connected in an intuitive way. The HiPerCopS IDE employs a top-down approach to the design task, allowing users to work from a big-picture perspective.

The componentized nature of the HiPerCopS architecture lends itself to extensive reuse. The same types of elements are used in many kinds of cells, the same types of cells are used in many modules, and so on. To prevent the user from having to define the same elements and cells over and over again, the HiPerCopS IDE allows commonly-used structures to be defined in libraries.

The HiPerCopS IDE supports four different libraries, one each for elements, cells, modules, and systems. The default members of these libraries have been chosen for their frequent use in a wide variety of applications. Each library is a collection of plain-text files at a common location. The library files feature flexible syntax that is easy to understand. No experience with a particular programming language is required. This allows users to easily customize the libraries. They can edit the existing definitions or add library files of their own. Such control maximizes the efficiency of the designer and allows for extensive customization.

Some elements, cells, modules, and systems are so common that they can be considered essential members of every HiPerCopS library. The files that describe these structures are included in every copy of the HiPerCopS IDE source distribution, and are described in Appendix A. Over time, it is expected that this common library will grow as the HiPerCopS architecture continues to develop. With this in mind, a global repository has been established to manage the common library. The repository enables users to update their local libraries whenever necessary, giving them the latest version of the common library. It also allows users to submit their custom library files to the repository, so others have the opportunity to leverage that work in their own designs. More information about the global repository can be found in Appendix A.

\section{Element Library}

\begin{table}
\caption{Basic element types}
\centering
\begin{tabular}{c | c c c}
\hline
Element Type & $\psi_{1}$ & $\psi_{0}$ & Same as\\
\hline
A & $MAJ(\alpha \wedge \beta, \gamma, \delta)$ & $XOR(\alpha \wedge \beta, \gamma, \delta)$ & A\\ 
B & $MAJ(\alpha \wedge \beta, \gamma, \delta)$ & $XOR(\alpha \wedge \beta, \gamma, \delta)$ & A\\ 
C & $MAJ(\alpha \wedge \beta, \gamma, \neg \delta)$ & $XOR(\alpha \wedge \beta, \gamma, \delta)$ & C\\ 
D & $MAJ(\alpha \wedge \beta, \gamma, \neg \delta)$ & $XOR(\alpha \wedge \beta, \gamma, \delta)$ & C\\ 
E & $MAJ(\alpha \wedge \beta, \gamma, \neg \delta)$ & $XOR(\alpha \wedge \beta, \gamma, \delta)$ & C\\
F & $MAJ(\alpha \wedge \beta, \neg \gamma, \delta)$ & $XOR(\alpha \wedge \beta, \gamma, \delta)$ & F\\
G & $MAJ(\alpha \wedge \beta, \neg \gamma, \delta)$ & $XOR(\alpha \wedge \beta, \gamma, \delta)$ & F\\
H & $\neg MAJ(\alpha \wedge \beta, \neg \gamma, \neg \delta)$ & $XOR(\alpha \wedge \beta, \gamma, \delta)$ & H\\
\hline
\end{tabular}
\label{table:element_types}
\end{table}

\begin{figure}
{\tt
\begin{singlespace}
\lstset{numbers=left, numbersep=20pt, frame=single, }
\lstinputlisting{../lib/element/A.lut}
\end{singlespace}
}
\caption{Library file for the type A element.}
\label{fig:elemfile_typeA}
\end{figure}

\begin{table}
\caption{Truth table for the type A element.}
\centering
\begin{tabular}{c || c | c}
$\alpha,\beta,\gamma,\delta$ & $\psi_{1}$ & $\psi_{0}$ \\
\hline
0000 & 0 & 0\\
0001 & 0 & 1\\
0010 & 0 & 1\\
0011 & 1 & 0\\
0100 & 0 & 0\\
0101 & 0 & 1\\
0110 & 0 & 1\\
0111 & 1 & 0\\
1000 & 0 & 0\\
1001 & 0 & 1\\
1010 & 0 & 1\\
1011 & 1 & 0\\
1100 & 0 & 1\\
1101 & 1 & 0\\
1110 & 1 & 0\\
1111 & 1 & 1\\
\end{tabular}
\label{table:truthtable_typeA}
\end{table}

In math mode, elements act as 4-input 2-output lookup tables. As shown in \cite{myjak_raw04}, most operations can be implemented by a small set of elements. These essential elements are listed in Table \ref{table:element_types}, and each of these elements is defined in the HiPerCopS element library by default. As shown in the table, this set can be reduced to the subset of element types A, C, F, and H, but all eight types are included in the library for the sake of completeness.

In the element library, the look-up table (LUT) of each element type is represented by a file with the *.lut extension. As an example, Figure \ref{fig:elemfile_typeA} shows the contents of A.lut, which defines the type A element. Notice that the first three lines of the file begin with the `{\tt \#}' character. These indicate comments that act as notes to the user. The remaining sixteen lines define the contents of the LUT array and are written in comma-separated value (CSV) format. These rows describe the binary values to be written to the element's array, and they can be conceptualized as entries in a truth table to show the relationship between the 4-bit input and the 2-bit output (Table \ref{table:truthtable_typeA}).

\section{Cell Library}

\begin{figure}
{\tt
\begin{singlespace}
\lstset{numbers=left, numbersep=20pt, frame=single, }
\lstinputlisting{../lib/cell/H.cell}
\end{singlespace}
}
\caption{Library file for the type H cell.}
\label{fig:cellfile_typeH}
\end{figure}

\begin{figure}
\centering
\includegraphics[scale=0.2]{img/H_cell}
\caption{Physical layout of an H cell.}
\label{fig:H_cell}
\end{figure}

Since cells have fixed dimensions and routing paths, they are even easier to describe than elements. The cell library file format is very simple, consisting of comments, a `{\tt [cell]}' heading, an `{\tt elements:}' section, and a CSV list of the elements. Figure \ref{fig:cellfile_typeH} displays the contents of library file H.cell. This library entry produces a type H cell, represented graphically in Figure \ref{fig:H_cell}.

It is important to note that the entries in the CSV portion of a cell file must match filenames in the element library directory. The HiPerCopS IDE recursively defines cells by building them out of their comprising elements.

\section{Module Library}

\begin{figure}
{\tt
\begin{singlespace}
\lstset{numbers=left, numbersep=20pt, frame=single, }
\lstinputlisting{../lib/module/add.module}
\end{singlespace}
}
\caption{Library file for an adder module.}
\label{fig:modulefile_typeAdd}
\end{figure}

Entries in the module library are more complex than cell library files. Since modules can be composed of different numbers of cells, and since the inter-cell routing rules can be different from module to module, module library files require more detailed information. An example of a module library file is shown in Figure \ref{fig:modulefile_typeAdd}, which defines a 32-bit adder.

Entries in the module library consist of a single heading and associated sections:

\begin{quote}
{\bf Module heading.} Every file in the module library must include the {\tt [module]} heading. This marks the subsequent sections as belonging to a module description. 

{\bf Cells section.} The {\tt cells} section is used to define the layout of the module's cellfield as well as the individual cell types for each position in the array. The names used in this CSV list must match filenames in the cell library directory.

{\bf Names section.} Cells in a module cellfield cannot be identified by their cell type alone. Often, modules contain many cells of the same type. However, since a module requires explicit rules for inter-cell routing, there needs to be some way for individual cells to be uniquely identified. The {\tt names} section contains a CSV list of the same dimensions as the {\tt cells} section. Its entries are comprised of unique strings that correspond to the cell located in that position. By establishing a mapping between the cell type and its unique name, the HiPerCopS IDE can associate specific routing rules with each particular cell.

{\bf Input sections.} Depending on the module, computational inputs must be applied to different cells in the cellfield. Each computational input is a bitstring that is split into substrings called `nybbles'. For the HiPerCopS architecture, nybbles are four bits long. Each nybble is applied to a different cell in the module cellfield. The {\tt inputs} sections contain a list of cell names which map the nybbles to the appropriate cell. The most significant nybble is applied to the first cell in the list, the second-most significant nybble is applied to the second cell in the list, and so on. Of course, the input list must have enough entries to accomodate every nybble of the input string, and vice versa.

Modules can accept multiple inputs, so module library files have a section for each input. For example, an $N$-input module will have sections named {\tt i1}, {\tt i2}, \ldots {\tt iN}. For the HiPerCopS architecture, modules take four bitstrings as arguments, so $N = 4$.

{\bf Output section.} Just as input configurations differ from module to module, the outputs of a cellfield do not follow a standard rule. Since this is the case, the sources and order of the output nybbles need to be defined in the module library file. The most significant nybble is listed first, the second-most significant nybble is listed second, and so on. The library file's routing specification determines which cell outputs are applied to particular output nybbles. 

{\bf Routing section.} The {\tt routing} section defines the module's cellfield interconnections. Its objective is to direct the outputs of each cell into the inputs of another. Routing sections in the module library are written using HiPerDOT, a custom variant of the DOT language (see Appendix B).

For modules, each line of a routing specification contains four parts, shown in Equation \ref{eq:module_routing_entry}. Each routing entry can map a single nybble of data from a source's output to a destination's input. To begin an entry, {\tt \{source\}} contains a cell name, indicating which cell's outputs are being routed. Another cell name is listed in the {\tt \{destination\}} field to show where the input should be routed. The `chunk' attribute specifies which nybble of the source's output to use. The value of {\tt \{nybble\}} can be either `msb' or `lsb,' referring to the most significant or least significant bits of the output. To direct the routed nybble to a particular destination cell input, the {\tt \textbf{index}} field is used. The {\tt \{abcd\}} entry is given a value in the range $[0, 1, 2, 3]$, which corresponds to cell inputs $a$, $b$, $c$, and $d$, respectively.
\begin{equation}  \label{eq:module_routing_entry}
{\tt \{source\} \longrightarrow \{destination\} [\textbf{chunk} = \{nybble\}, \textbf{index} = \{abcd\}]};
\end{equation}

{\bf Comments.} As with the other library files, comment lines are indicated by the `{\tt \#}' character. Comments can be placed anywhere in the file and will be ignored by the library parser.
\end{quote}

\section{System Library}

\begin{figure}
{\tt
\begin{singlespace}
\lstset{numbers=left, numbersep=20pt, frame=single, }
\lstinputlisting{../lib/system/easy_system.dot}
\end{singlespace}
}
\caption{Library file for a simple system.}
\label{fig:systemfile_simple}
\end{figure}

\begin{figure}
\centering
\includegraphics{img/easy}
\caption{Simple system displayed as a diagram.}
\label{fig:systemdiag_simple}
\end{figure}

Systems use entries in the module library to create powerful, complex applications. Since the HiPerCopS IDE facilitates system design at a high level, users will spend most of their time working with system library files. For this reason, the syntax and format of system library files were designed to balance simplicity and verbosity.

As shown in Figure \ref{fig:systemfile_simple}, every system library file has two major sections: module declaration and routing. The module declaration section lists variable names that will be used in the routing section. Each variable represents a module, and the module's type is determined by the label field. A variable's label must match the filename of a module library entry. If it does not, the HiPerCopS IDE will not be able to construct the associated underlying data structures or map the module to the device.

The routing section of a system library file describes how the inputs and outputs of the system's modules are connected. Each routing entry consists of a source and a destination, with directionality indicated by an arrow (Equation \ref{eq:system_routing_entry}). The source and destination values must correspond to a variable from the module declaration section.
\begin{equation}  \label{eq:system_routing_entry}
{\tt
\{source\} \longrightarrow \{destination\};
}
\end{equation}

Information contained in DOT files can be displayed graphically, giving the user another way to inspect their systems. For instance, the system described by the code in Figure \ref{fig:systemfile_simple} can be processed and displayed as the diagram in Figure \ref{fig:systemdiag_simple}.
